Related PRs:

• [RNMobile] Avoid keyboard dismiss when interacting text blocks wordpress-mobile/gutenberg-mobile#6467
• [For testing] [TEST][Gutenberg] Avoid keyboard dismiss when interacting text blocks wordpress-mobile/WordPress-iOS#22235
• [For testing] [TEST][Gutenberg] Avoid keyboard dismiss when interacting text blocks wordpress-mobile/WordPress-Android#19795

What?

This PR solves the following cases that are affected by the keyboard’s disruptive hide-and-show behavior:

• Insert a new block by pressing the enter key in a text-based block.
• Merge blocks by pressing the backspace key in a text-based block.

However, there's a remaining case that this PR won't cover:

• Replace blocks when interacting with the List block.

We haven't found a solution to this yet, as a next step, we'd need to explore further the actions performed during block creation and merging in the List block.

Why?

This PR will greatly improve the usability when writing content, as the hide-and-show behavior impacts negatively the editing experience.

How?

Solve blur/focus event conflicts

Each RichtText component instance triggers blur/focus events based on its state (e.g. will be unmounted, gains/loses selection) without considering other instances states. This leads to conflicts between blur and focus events in different cases like pressing enter on a Paragraph block to insert a new paragraph.

Here is an example of the sequence of events generated when pressing enter:

• Paragraph 1 triggers blur event. This comes from the componentDidUpdate function due to changing its selection state from selected to unselected.
  • This blur is the culprit of the keyboard being dismissed, as it executed first.
• Paragraph 2 triggers focus event when it's mounted (i.e. from the componentDidMount function).
• This focus event makes the keyboard to open.
• Paragraph 2 triggers focus a second time. However, this event is innocuous. This comes from the componentDidUpdate function due to changing its selection state from unselected to selected.
• Paragraph 1 triggers blur event. This comes from the _onBlur callback triggered by Aztec because the text input lost focus. This event is innocuous.

To solve this conflict, this PR introduces the usage of debounce in the blur event (b6f237f). It will ensure that focus events take precedence when blur events have been triggered at the same time, as well as cancel them to avoid the keyboard to be dismissed.

iOS - Keyboard dismisses automatically when text input is removed

Another case to solve is when two blocks are merged. The editor internally replaces the blocks which implies removing one of them. On iOS, this presents a problem because the keyboard will be automatically dismissed. No blur events are generated so a different approach was taken.

The solution (a71b1c5) implied tweaking the order of native commands invoked for blur and focus events (reference). The focus event triggered by the new block created (i.e. the one that contains the merged content) happens at the same time the other block is removed. So, the workaround for this case is to ensure that focus events are prepended in the pending UI blocks list of the UIManager (reference 1 , reference 2).

Android - Avoid triggering blur events on unmounted instances

As mentioned below, when RichText/AztecView is unmounted a blur event is triggered. On Android, this behavior in combination with using debounce leads to an exception because we try to blur a text input that no longer exists. To address this, a new function has been introduced in the Aztec input state (blurOnUnmount) that is only called for the component unmounting case (634867f). This function has two purposes:

1. Cancel potential previous blur calls to avoid exceptions.
2. Hide the keyboard, as it would happen in a regular blur event. Note that the call to hide the keyboard uses debounce. This is needed to avoid dismissing the keyboard if a focus event happens at the same time.

Other changes

As a side note, the blur event triggered when unmounting the RichText component has been moved to the AztecView component as seems a better fit for this logic (d3fb486).

Testing Instructions

1 - Post title

1. Open the app.
2. Create an empty post.
3. Observe that the title is focused.
4. Type some words and press enter.
5. Observe the following:
   1. The Paragraph block is focused.
   2. The keyboard remained open when transitioning.
6. Press backspace.
7. Observe the following depending on the platform:
   1. Android
      1. The Paragraph block remains focused.
      2. The keyboard remains open.
   2. iOS
      1. The Paragraph block remains focused.
      2. The keyboard reopens (this should be tackled in the future)

2 - Insert a new block by pressing the enter key in a text-based block

1. Open the app.
2. Create an empty post.
3. Select the first Paragraph block.
4. Type some words and press enter.
5. Observe the following:
6. A new Paragraph block is created and focused.
7. The keyboard remained open when transitioning.

3 - Merge blocks by pressing the backspace key in a text-based block (iOS only)

1. Open the app.
2. Create an empty post.
3. Select the first Paragraph block.
4. Type some words and press enter.
5. Press backspace.
6. Observe the following:
   1. The second Paragraph block is removed.
   2. The first Paragraph block is focused and the text caret is at the end of the content.
   3. The keyboard remained open when transitioning.
7. Place the text caret between two words.
8. Press enter.
9. Observe the following:
   1. The paragraph is split into a new Paragraph block and it's focused.
   2. The keyboard remained open when transitioning.
10. Press backspace.
11. Observe the following:
    1. The paragraph is merged with the first one and it's focused.
    2. The keyboard remained open when transitioning.

4 - Automatically dismiss the keyboard when selecting non-text-based-blocks

1. Open the app.
2. Create an empty post.
3. Add an Image block and set an image.
4. Tap on the caption field.
5. Observe the following:
   1. The caption field is focused.
   2. The keyboard opens.
6. Type some words and press enter.
7. Observe the following:
   1. A new Paragraph block is created and focused.
   2. The keyboard remained open when transitioning.
8. Press backspace.
   1. The Image block is selected.
   2. The keyboard closes.
9. Insert a Paragraph block and type some words.
10. Observe that the Paragraph block is focused.
11. Tap on the Image block.
12. Observe the following:
    1. The Paragraph block is no longer focused.
    2. The keyboard closes.

5 - Manually dismiss the keyboard

1. Open the app.
2. Create an empty post.
3. Select the first Paragraph block.
4. Observe the following:
   1. The Paragraph block is focused.
   2. The keyboard opens.
5. Tap on the keyboard icon located in the toolbar.
6. Observe the following:
   1. The Paragraph block is no longer focused.
   2. The keyboard closes.

6 - The keyboard is dismissed and restored when opening modals

NOTE: On Android, this case will be covered by #57069.

1. Open the app.
2. Create an empty post.
3. Select the first Paragraph block.
4. Open the block settings.
5. Observe the following:
   1. The Paragraph block is no longer focused.
   2. The block settings bottom sheet opens.
   3. The keyboard closes.
6. Dismiss the bottom sheet.
7. Observe the following:
   1. The Paragraph block is focused again.
   2. The keyboard opens.
8. Navigate to the bottom of the post.
9. Tap on the empty area below the content.
10. Observe the following:
    1. A new Paragraph block is created and focused.
    2. The keyboard remained open when transitioning.

6 - Writing flow

It's recommended to cover the writing flow test suite by manually testing.

Testing Instructions for Keyboard

N/A

Screenshots or screencast